Description

When the brokerage supports concurrency, the transaction handler used a fixed number of threads. This replaces that with a pool that starts at minimum-transaction-threads (2) and grows up to maximum-transaction-threads (10), adding a thread only when every existing thread is busy with requests still waiting.

Each order (or combo group) is pinned to one queue for its lifetime, so all its requests are processed in order by the same thread even after the pool grows. The synchronous backtest path is unchanged.

Motivation and Context

N/A

Requires Documentation Change

N/A

How Has This Been Tested?

It was tested using unit tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>